A common issue for network operators operating telecommunications networks (such as network operators operating traditional 2G mobile networks, or the most recent 3G networks) is the technical complexity of subscription provisioning, which can in turn lead to increased capital expenses (CAPEX) and operational expenses (OPEX) due to inefficient pre-provisioning.
Commonly, the services offered to end-users in different point-of-sales (e.g. shops where a terminal connectable to the telecommunications network can be acquired) comprise a combination of: basic circuit switch, CS, and/or packet switch, PS, services (e.g. which allows a user to establish from his terminal a voice communication with another terminal, and/or establish a data connection with another terminal or with a server on the Internet), network implemented services based on e.g. CAMEL (“Customised Application for Mobile network Enhanced Logic”), and, in most of the cases, also some applications services provided by application servers cooperating with network nodes, such as positioning based services, messaging services allowing the delivery of e.g. SMSs, e-mails, etc.
The set of data held by nodes of a telecommunications network for providing and/or adapting services to a given terminal connectable to the network is usually known, and also referred to herein, as “service profile” or “service profile data” or “profile data”. Commonly, each terminal connectable to a telecommunications network is assigned to a “service profile”, which is stored by the network (e.g. within a HLR or HSS as a master storage) in relationship with an identifier of said terminal (e.g. IMSI, MSISDN, etc), and at least a part of it also stored by the terminal.
Before a user or device is able to gain access to the services of a network, the user or device must previously have been “provisioned” in the network, with subscriber and related service data being registered in central databases such as the Home Subscriber Server (HSS) and Subscription Locator Function (SLF).
Given that normally it is difficult for the network operator to know when the end user terminal is to be acquired in a point-of-sales, and the corresponding user's related services subsequently activated, the network nodes as well application servers are usually pre-provisioned in advance with service profile data for each terminal (i.e. in relationship with identifier/s of said terminals) long before the corresponding terminal activation takes place.
This is a handicap for the operator, as it has to pre-provision its network nodes (e.g. HLRs, HSSs, charging nodes, etc) a long time before the services related to an identity of a terminal (e.g. its IMSI, its MSISDN, etc) are used. It might even happen that a given pre-provisioned service in relationship with an identity of a user terminal is never used (e.g. because the user finally acquiring a terminal does not want to user packed switch based services). This leads to a waste of network resources, which in turn leads to wasted CAPEX and OPEX. For example, since the precise instant a user terminal would perform the initial attach for a subscription is uncertain, all the sold (or waiting to be sold) subscription related data for said terminal must be pre-provisioned in the HLR/HSS/AuC, which lead to an inefficient use of HLR/HSS capacity.
To be able to overcome these problems, different functions focused in avoiding pre-provisioning of core network nodes in advance to terminal activation have been developed, allowing that the provisioning of these nodes only occurs when it is needed; for example, when the end-user terminal first attaches to the telecom network. These mechanisms are commonly known as auto-provisioning mechanisms. Details of these mechanisms are described below.
These automated provisioning mechanisms fit well when the terminals to be sold (and, subsequently, activated) are the so called Machine-to-Machine (M2M) devices (also referred herein as M2M equipments, “M2ME”).
M2M devices are terminal equipments which can be arranged to connect to current telecommunications networks (e.g. 2G or 3G networks), but which are not intended to be operated by human users for originating or terminating communications (i.e. the traditional end user terminals). Instead, M2M devices are arranged to be self-operated to, for example, transmit automatically a measured parameter (e.g.: temperature, humidity, speed, etc) to a specific server in the network; for example, at certain intervals, or when a measured parameter exceeds a given threshold. Circuit Switch (CS) and/or Packed Switch (PS) bearer connection services can be used by M2M devices to transmit their data, as well as to receive data. Accordingly, configuring a M2M device with the necessary data to connect to a specific server in the network where to send its data can be a part of the provisioning tasks.
M2M deployments involve scenarios comprising: M2M manufacturers, companies acquiring M2M devices, and telecom network operators that can use its own (or roaming agreed) infrastructure to provide communication services also to the M2M devices. The number of M2M devices that can be put into operation to communicate through current telecommunications networks is expected to increase drastically in the coming years.
Taking into account the specific M2M characteristics, it is envisaged that a huge number of M2M devices can be manufactured (e.g. adapted to measure a temperature, and to transmit data related to it) and preconfigured with certain data for its operation; namely: before they are acquired by a certain company that can benefit from the data transmitted from the M2M devices, before said company acquires subscriptions with a network operator operating a telecom network allowing communications from/to these M2M devices and servers in the network, and before these devices are finally put into operation so as to be able to attach to said telecom network and to subsequently transmit and/or receive the necessary data. Nevertheless, performing said kind of pre-configuration in advance can result in an increase of M2M device production costs, and/or in lack of adaptation of M2M devices for all the eventual companies that might acquire them; being that the reason why auto-provisioning is preferably used for configuring certain operational data into M2M devices.
However, the present applicant has appreciated that, in all the existing solutions today for auto-provisioning, both: the mechanism to select the final node(s) that will host the final provisioned data for a given end-user terminal or M2M device (e.g. a HLR, HSS, etc), and the mechanism to select the data to be provisioned (i.e. downloaded) to said end-user terminal or M2M device, are static since they are based on the identifier(s) associated to the end-user terminal or M2M device, which conditions the nodes hosting the data to be provisioned, as well as the data to be provisioned (e.g. profile data are statically related to identifiers of terminals and M2M devices).
To illustrate this, previously-considered approaches to auto-provisioning will now be described.
A generic auto-provisioning scenario will first be described with reference to FIG. 1 of the accompanying drawings. The signaling flows illustrated in FIG. 1 show some basic interactions for auto-provisioning that would happen in a generic telecommunications network. It describes how the necessary data for operating a terminal (i.e. a traditional end user terminal, or a M2M terminal can be provisioned within telecom network nodes (generally represented below as “access network) in an automated manner (i.e. without requiring operator's O&M staff intervention) upon detecting the device first attach into the network (i.e. a traditional end user terminal, or a M2M terminal).
The steps in such a generic auto-provisioning scenario are given below, with reference to FIG. 1.    (0) Prior to step 1 shown in FIG. 1, a terminal (e.g. M2M device or M2ME) is provisioned with a minimum profile to be able to access the network with very restricted services.    (1) The M2M device accesses the network for the first time using its pre-provisioned minimum profile.    (2) The access network allows the access with the predefined minimum profile and notifies the provisioning system that a new user has attached in the network, so further provisioning is started. (Meanwhile, the user/M2M device can use the minimum set of services).    (3) In order to be able to complete the provisioning of the core network nodes, the provisioning system looks for the subscription data to provide for the involved M2M Device. It is important to note that these data are static data pre-stored in a database in relationship with identifier(s) of the M2M device, which is/are received by the network in the previous flows.    (4) The provisioning system builds or selects the profile to assign to the M2M device/end-user in each core network node.    (5) The Network node(s) is (are) provisioned accordingly. The M2M device is also provisioned with data according to the services included in the definitive/final profile assigned to the M2M device.    (6) The M2M device can access to the new services provided to it.
Service profile auto-provisioning in HLR will now be described with reference to FIG. 2 of the accompanying drawings. This part illustrates details of an auto-provisioning flow as described above when the telecommunications network comprises a home subscriber server, such as a HLR/AUC or a HSS.
The steps in a typical service profile auto-provisioning scenario are given below, with reference to FIG. 2.    (0) AUC is provisioned with authentication data for the M2M device. GPRS access is configured in the HLR for certain number series (that includes this M2M device).    (1) The M2M device accesses the network using its minimum profile with only GPRS access. This involves sub-steps 1.a to 1.g as summarised in FIG. 2.    (2) The HLR notifies the provisioning system so further provisioning is started. (Meanwhile, the M2M device can use the minimum set of services).    (3) Provisioning system gets static input data from a database, which were stored beforehand in relationship with identifier(s) of the currently attaching M2M device.    (4) Provisioning system conforms/builds/selects the profile.    (5) The HLR is provisioned.    (6) Other Network nodes are provisioned accordingly.    (7) Optionally, M2M device is informed about his new profile.    (8) The M2M device can access to the new services provided to him.
Remote subscription management specific for M2M devices (Selection of Operator or Hosting node) will now be described with reference to FIG. 3 of the accompanying drawings. This part illustrates signaling flow details of an auto-provisioning flow to provisioning of MCIM data for M2M devices as described by 3GPP TR 33.812 V9.2.0 (June 2010; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Feasibility study on the security aspects of remote provisioning and change of subscription for Machine to Machine (M2M) equipment) in section 5.1.3.6.3 and its FIG. 5.1.3.6.3-1 (included as FIG. 3 of the accompanying drawings).
The acronym MCIM stands for “Machine Communication Identity Module”. In short, it comprises a collection of data and executable software for—among other functions—identifying the corresponding M2M device and for running authentication procedures before the telecom network. Thus, to some extent a MCIM application is equivalent to “Subscriber Identity Module” applications (such as SIM, USIM or ISIM applications) commonly residing in a “Universal Integrated Circuit Card”, UICC, connectable to traditional 2G/3G mobile user terminals. (USIM is Universal Subscriber Identity Module; DLUSIM is a Downloadable USIM.)
The MCIM data that are downloaded to a M2M device at this stage (as illustrated in the figure below) can comprise connectivity service data, which can then be used by the M2M device in further communications to establish a connection through the telecom network with the specific application server where to send its data (e.g. measured temperature, humidity, speed, etc).
The scenario, with regard to a 3G telecommunications system comprising a complex multi-network operator scenario having: a Visited Network Operator (VNO), which is accessed from the M2M device for getting access to the 3GPP system; a Registration Operator (RO), which, in cooperation with the VNO, allows the registration of the M2M device within the 3GPP system; and a Selected Home Operator (SHO) to which the M2M device is intended to be subscribed, and which, in cooperation with the RO, allows the provisioning of the M2M device when initially attaches to the 3GPP network. However, in some real-life situations, the (complex) access and provisioning scenario illustrated below by FIG. 3 can be simpler, and e.g. the VNO and the RO can be the same physical network operator.
The meaning of the acronyms and specific terms cited in FIG. 3 and by the accompanying description, as well as the description of some functional entities referred herein, are disclosed in detail by the aforementioned document 3GPP TR 33.812, and/or within its cited references. However a brief explanation of them is provided below.
The items “VNO”, “RO” and “SHO” in the figure below represent in a simplified and grouped manner, nodes in the different network domains of said operators (i.e., respectively: Visited Network Operator, Registration Operator and Selected Home Operator.
In particular, the domain of the RO can comprise one or more nodes implementing the following functional entities:                Initial Connectivity Function (ICF). It is a functional entity for providing initial connectivity for the M2M equipment to request downloading and provisioning of data (e.g. final credentials, application data, etc.) to the M2M equipment.        Discovery and Registration Function (DRF). It is a functional entity for allowing a M2M equipment to discover and register with the corresponding SHO.        Download and Provisioning Function (DPF). It is a functional entity for managing the downloading and provisioning of data (e.g. final credentials, application data, etc) to the M2M equipment in cooperation with nodes of the SHO.        
In turn, the domain of the SHO can comprise, or have access to, a:                Platform Validation Authority (PVA). It is a functional entity for validating the credentials used to verify a M2M equipment as a trusted platform allowed to access the telecommunications network.        
In some cases, the role of the PVA and the DPF may be hosted by nodes within the SHO.
The steps below describe (with reference to FIG. 3) signaling flow details of an auto-provisioning flow to provisioning of MCIM data for M2M devices as described by 3GPP TR 33.812 V9.2.0.
Steps 1 to 5 describe the phase of initial attach of a M2M device using its pre-provisioned provisional credentials and its pre-provisioned provisional service profile data for achieving an initial connectivity.    (1) The M2ME uses the standard GSM/UMTS functions (GPRS/PS) to decode network information and attaches to the network of any VNO. In the attach message the M2ME sends a Provisional Connectivity ID (PCID) to the VNO. To avoid that the VNO needs to support special M2M functionality, the PCID has the same format as the IMSI. The “MCC” and “MNC” fields in the PCID will indicate to the VNO which entity it should contact to obtain authentication vectors to authenticate the PCID with.    (2) The VNO contacts the RO (ICF function) and sends the PCID-IMSI to the ICF. Note that in some cases the RO and VNO may be the same operator.    (3) Upon receiving the PCID-IMSI, the ICF queries the temporary-access credential associated with the PCID in its database. According to the credential, the ICF can generate AVs.
NOTE 1: If the ICF is not already in possession of the used PCID-IMSI and related temporary-access credential, it can obtain it from the CCIF.    (4) The RO transfers AVs for the claimed PCID-IMSI to the VNO.    (5) The VNO uses the AV to authenticate the M2ME through the AKA.
Steps 6 to 10 describe the phase of discovery and registration.    (6) The ICF request the DRF to bootstrap. Internally, the RO forwards the PCID and the IP address of the M2ME from its ICF to its DRF function.    (7) According to the PCID-IMSI, the DRF queries the address of the DPF and the SHO which has contract with the M2ME in its database. It is important to note that this is a static procedure, since the SHO/DPF for this M2M device is pre-provisioned in DRF database in relationship with identifier(s) of said device, which is/are obtained in these signaling flows. Then it generates the Bootstrap message.    (8) The DRF sends the Bootstrap message to the M2ME. In the message it includes the IP connectivity parameters (NAPDEF), the address of the DPF (Server URL), the context of the MCIM application provision and the context of the M2M application provision. If the provided PCID-IMSI already points to the RO, the RO could become the SHO, and then the IMSI is just continued to be used.    (9) Triggered by the Bootstrap message, the M2ME contacts the DPF and includes relevant information of the M2ME and the TRE (e.g. platform validation info). TRE is “Trusted environment”, a functional area within a M2M device arranged to store, among other, MCIM data.    (10) The RO (DPF function) connects to the SHO, and relays the M2ME/TRE info there. Note that this is a static procedure, since, as mentioned earlier for step 7, the SHO corresponding to a certain M2M device identifier is pre-provisioned in DPF database or received from DRF.
Steps 11 to 19 describe the phase of MCIM application provision to the M2M device, which includes downloading to it, among other, the final (i.e. definitive) credentials, as well as other service profile data, which are to be used thereinafter by the M2M device.    (11) The SHO sends the validation info signed by the PfC and TRE identity to a PVA and requests a PVA to validate the authenticity and integrity of the TRE.    (12) The PVA locally validates the authenticity and integrity of the M2ME, according to the requirements of the SHO.    (13) The PVA sends the validation results back to the SHO, according to the SHO requirements.    (14) The SHO encrypt the MCIM by using the PfC and generate the management object for M2M (e.g MCIMobj).    (15) The SHO delivers the encrypted MCIM (e.g. within MCIMobj) to the RO (DPF) and authorizes provisioning of the MCIM application to the M2ME.    (16) The RO (DPF) downloads a MCIM object to the M2ME.    (17) The M2ME provisions the downloaded MCIM into the TRE. The TRE decrypts MCIMobj by using the TRE Platform Key to obtain the MCIM.    (18) The M2ME reports the success/failure status of the provisioning to the RO (DPF).    (19) The RO (DPF) reports the success/failure status of the provisioning back to the SHO
The present applicant has appreciated several issues with the existing solutions.
As mentioned earlier, the solutions that exist today for auto-provisioning are limited due to the lack of flexibility they show to select, both: the final node that will host the final provisioned data for a terminal (e.g. traditional end-user terminal or M2M device), as well as the data to be provisioned to said terminal. The current static auto-provisioning mechanisms (i.e. based on the identifier/s provided by the terminal when attaching to the network) can fit well for traditional end-user terminals; however, they might not suit so well for automated provisioning of M2M devices. As commented above, as opposed to terminal equipments intended for being controlled by human users (such as typical mobile phones) wherein the human user operating the terminal decides, on a case by case basis, the destination equipment for a communication (e.g. other terminal, or a given application server hosting a service, such as a web browsing service), the so called M2M devices are intended to establish communications in an automated manner with only certain destination equipments, which commonly is an application server arranged to collect and process measured temperatures from certain M2M devices. This implies configuring each and every M2M device with the necessary connectivity service data that, once these devices are connected to a telecommunications network, will allow them to individually establishing their respective communications through said network for communicating with the specific servers where to send their respective data.
The connectivity service data mentioned above can comprise, for example: an identifier of a service center for SMSs, and/or an “Access Point Name, APN” for PS based services via GPRS, and/or a “Uniform Resource Locator, URL” usable to address a certain application server, and/or an IP address of a certain application server. For most of the terminal equipments intended for being controlled by human users, these data can be controlled by the human user on a per individual communication basis. However, as cited above, that is not the case for M2M devices.
Configuring data (e.g. connectivity related data, as cited above) within M2M devices before they are finally acquired and put into operation (e.g. before a set of M2M devices are acquired by a company, or before said company acquire the necessary subscriptions to subscribe them to a network operator, or before these M2M devices first attach to the telecom network of a certain network operator) tends to increase the production costs for the M2M manufacturers, and/or increase acquisition and adaptation costs for the company buying them.
On the other hand, relying on prior art auto-provisioning static techniques can result in an unnecessary consumption of resources for the operators of the telecommunications networks. In particular, the databases accessed by the provisioning systems of said operators will have to store in advance, among other, connectivity data for each and every M2M device that can eventually attach to their network domains within a telecommunications network (i.e. data that should be pre-stored in relationship the respective identifier/s of each and every M2M device), so that both, a M2M device and the corresponding network node/s (e.g. HLR, HSS, etc) are provisioned accordingly when the M2M device is put into operation. These data stored in advance might however do not fit well for each and every M2M device when they are respectively put into operation and connect to a telecom network and, in any case, forces to coordinate detailed information about the intended usage of each M2M device between: M2M manufacturers and/or acquirers, and network operators.
It is desirable to address the above-identified issues.